While modern application programs provide various specialized functions tailored to meet the needs of particular types of clients, these applications utilize, at their core, a number of common functions. While the code to execute these common functions may easily be incorporated into each application program, such would increase the size and complexity of these application programs, and would increase their cost due to the increased manpower needed to duplicate code for these common functions. Because so many common functions exist, it was recognized early on that the code for these functions could be stored in an accessible library, the components of which could simply be called by the application program when such a function were needed. This greatly simplifies the programming necessary within an application and reduces the cost associated with the initial coding and development of that program.
The various functions are contained in separately named files which are called by the application program when that function is to be performed. In a Windows environment, such shared functions are stored in dynamic link library (DLL) files ending with the extension .dll. All these .dll files are typically stored in a common directory, e.g. c:\WinNT\System32\*.dll. While many core .dll files are provided with the operating system, new application programs loaded on a computer are often shipped with the .dll files needed for its proper operation. During installation of the application program, the application and all of its components (.dll files) are installed. If one of the shared components already exists, most installation programs will simply overwrite the already installed .dll file with the component included with the application that is being installed. While some installation programs provide the user with a choice of whether or not to install the shared component that is provided with the application program, choosing not to install this .dll file may result in the application being installed not working properly. Therefore, most users typically install all the components provided with the application program to ensure its successful operation.
However, while installing the provided .dll file should guarantee successful operation of the application being installed, it is no guarantee that applications installed previously that use that same shared .dll file will continue to operate properly with the version that overwrote the shared component that was originally installed when the other program was installed. Unfortunately, since the code that loads the .dll files does not express any versioning information of the .dll that it wants to load, and hence loads any .dll that has the same name as that for which it was looking, a subsequent failure of an application program to operate properly due to a shared component being overwritten with a different version of that component was difficult to fix.
A feature provided in the Windows ME operating system called “System Restore” allows users to essentially choose which versions of the shared components to put in the shared location. This feature keeps track of every time a user installs or uninstalls an application, and records the state of things like the registry and the contents of the directory \winnt\system32 before and after the install or uninstall. When a user chooses to rollback, the feature simply installs or uninstalls applications to try to get back to the state that existed before the last install or uninstall. In this way, if the installation of a new application causes other applications to break due to the overwriting of the shared component with a new version of that component, System Restore allows the user to effectively reinstall the old version of the shared component so that all application programs will use that older version of that shared component. If the new application will not operate properly with the old version of the shared component, System Restore will allow the user to replace that older version with the newer version so that the new application can operate correctly, although the old applications may again break. This presents a significant advantage over prior system that did not have this ability. However, this system still allows only a single shared component that must be used by all applications that require that shared component to be stored in the shared location. As such, a user may have to access the system restore function multiple times to operate different application programs in the situation just discussed.